Subject: DLSw Multicast Single Tunnel position

From: David Bryant/HQ/3Com <[email-masked]>
Date: 11 Oct 96 14:23:05 EDT

Just for the record, here's my position on the single tunnel race 
condition issue.

I think we should use a source and dest port of 2067 and let 
TCP resolve the race conditions.  DLSw is already complex and 
cpu heavy, I don't see the need to add something to it that already
exists at the lower layers.

I recognize that certain implementations may not be able to
accomodate sending a specific source port, but to the best 
of my knowledge, only one vendor has this issue.  Since DLSw 
scalability enhancements are an optional enhancement, it 
doesn't seem to make much sense to over complicate the protocol
to resolve one vendor's implementation problem.  Are there other 
vendors with this problem??

Regards, 
Dave

---

From: Scott Bales <[email-masked]>
Date: Tue, 15 Oct 1996 17:30:08 -0400

Dave (et al) -

The following comments should be read with the knowledge that we (Cisco) are
the vendor that would have the TCP implementation problem.

The proposal to use 2067 as both source and destination port is at best an
unusual TCP implementation.  Given that it is not illegal, I don't think we
would object as strongly if it solved the problem; however, it solves only 
part of the problem.  It does nothing to alleviate the race conditions 
involving both 2067 (single-port) and 2065 (RFC1795) bringups.  Given that 
these race conditions have to be resolved, we would propose that random 
source ports be permitted in the single-port bringup case, and that we 
address those (relatively simple) race conditions in the spec.  If this 
causes a delay, then so be it.

If a decision is made to use 2067 as both source and destination port, we
would choose not to implement support for single-port bringup.  However, in
that case we would *vigorously* oppose requiring or assuming single-port 
bringup support in the Multicast/Unicast and Peer-on-Demand (V1.1) spec.
While it may be desirable, there is nothing about single-peer bringup that
is logically required for the Multicast support.

 - Scott Bales, Cisco Systems

-->  From [email-masked]  Sat Oct 12 02:19:24 1996
-->  From: David.Bryant/HQ/[email-masked]
-->  
-->  Just for the record, here's my position on the single tunnel race 
-->  condition issue.
-->  
-->  I think we should use a source and dest port of 2067 and let 
-->  TCP resolve the race conditions.  DLSw is already complex and 
-->  cpu heavy, I don't see the need to add something to it that already
-->  exists at the lower layers.
-->  
-->  I recognize that certain implementations may not be able to
-->  accomodate sending a specific source port, but to the best 
-->  of my knowledge, only one vendor has this issue.  Since DLSw 
-->  scalability enhancements are an optional enhancement, it 
-->  doesn't seem to make much sense to over complicate the protocol
-->  to resolve one vendor's implementation problem.  Are there other 
-->  vendors with this problem??
-->  
-->  Regards, 
-->  Dave
-->

---

From: David Bryant/HQ/3Com <[email-masked]>
Date: 16 Oct 96 9:12:30 EDT

Scott - 

I'm of the belief that if we go to the effort of delaying the spec 
for single tunnel, then we should require it as part of this implementation.
I also think it is pretty important in order for peer on demand function 
to work well.  It eliminates many of the flows in getting a tunnel established 
and
will likely prevent XID and/or SABME timeouts.

On the topic of support for race conditions with 2065 and 2067,  this sounds
like a misconfiguration example, right? One node wants to run in RFC1795
mode and the other in Single Tunnel mode.  Since RFC1795 tunnels need
to be predefined anyway, this situation must be a misconfiguration.  In 
addition, a Single Tunnel node shouldn't be sending to 2067 unless it had
a reason to believe the receiving node would respond (i.e., it received a
UDP based ICANREACH_ex). 

Nevertheless in this case, I would think that the RFC1795 implementations 
already 
have a timeout when the second tunnel to 2065 never comes up.   And similarly, 
the
attempt to connect on 2067 would not succeed because the other node would
not be listening/responding on that port.  So this misconfiguration case does 
not 
seem to be meaningful to me. 

Thoughts?

Dave

----- Previous Message ---------------------------------------------------- 

To: aiw-dlsw-scalability  @ www.raleigh.ibm.com @ UGATE
cc: David_Bryant  @ 3mail.3com.com @ UGATE 
From: sbales @ cisco.com (Scott Bales) @ UGATE    
Date: Tuesday  October 15, 1996 05:30 PM
Subject: Re: DLSw Multicast Single Tunnel position
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Dave (et al) -

---

From: Scott Bales <[email-masked]>
Date: Wed, 16 Oct 1996 18:45:39 -0400

-->  From [email-masked]  Wed Oct 16 15:47:29 1996
-->  To: Scott Bales <[email-masked]>
-->  Cc: aiw-dlsw-scalability <[email-masked]>,
-->  
-->  Scott - 
-->  
-->  I'm of the belief that if we go to the effort of delaying the spec 
-->  for single tunnel, then we should require it as part of this implementation.

Agreed.  And I would like to see us reach agreement on the single-tunnel bringup
as I feel this could be a major win for everyone.  I just don't feel that requiring
a source port of 2067 is the right way to do this.

-->  I also think it is pretty important in order for peer on demand function 
-->  to work well.  It eliminates many of the flows in getting a tunnel established 
-->  and
-->  will likely prevent XID and/or SABME timeouts.
-->
-->  On the topic of support for race conditions with 2065 and 2067,  this sounds
-->  like a misconfiguration example, right? One node wants to run in RFC1795
-->  mode and the other in Single Tunnel mode.  Since RFC1795 tunnels need
-->  to be predefined anyway, this situation must be a misconfiguration.  In 
-->  addition, a Single Tunnel node shouldn't be sending to 2067 unless it had
-->  a reason to believe the receiving node would respond (i.e., it received a
-->  UDP based ICANREACH_ex). 

I don't think that this is necessarily a misconfiguration.  Your comment seems to
presuppose that single-pipe bringup could only be used as a result of a resource
found via Multicast/Unicast.  I do not recall this ever being discussed as a
requirement; in fact, I suspect some vendors would like to incorporate the advantages
of a single pipe bringup in their configured peers.

-->  Nevertheless in this case, I would think that the RFC1795 implementations 
-->  already 
-->  have a timeout when the second tunnel to 2065 never comes up.   And similarly, 
-->  the
-->  attempt to connect on 2067 would not succeed because the other node would
-->  not be listening/responding on that port.  So this misconfiguration case does 
-->  not 
-->  seem to be meaningful to me. 

Again, I don't agree.  This comment presupposes a requirement that RFC 1795 bringup
could never be used if a peer is capable of single-pipe bringup.  While it is true
that Peers-on-demand would be required to use single pipe bringups and should never
run into such race conditions, single pipe bringup is *not* designed to be specific
to POD, and such race conditions could exist in the case of configured peers.  In this
case, it is incorrect to assume that a peer would not respond on 2067 if it attempted
to connect on 2065.

I think what I'm hearing is that using a source port of 2067 resolves all race
conditions specifically related to Peers-on-Demand given that they are required
to use single pipe bringup.  My problem with this is that it does not resolve all
the race conditions related to other uses of single-pipe bringup (configured peers).
I feel we cannot release any spec that doesn't handle these race conditions.  And
if we're going to have to handle race conditions anyway, we should use a more
standard approach of allowing random source ports, and handle the (relatively simple)
race conditions that result.

Handling race conditions with both peers using 2067 could really be quite easy - the
peer with the {higher | lower} IP address closes the pipe that {it | it's peer} opened.
Pick one from each grouping of two options - I don't think it matters.  It's the
race conditions involving both ports 2065 and 2067 that are much more complex, in
my opinion.

The alternative is to allow single-pipe bringup to be used only for Peers-on-demand,
but I think it would be a real shame for this group to paint themselves into that
corner just because we're in a hurry to get the V1.1 spec out.  This has a potential
to be a useful tool far beyond the scope of POD's.

 - Scott

-->  Thoughts?
-->  
-->  Dave
-->  
-->  
-->  ----- Previous Message ---------------------------------------------------- 
-->  
-->  
-->  
-->  To: aiw-dlsw-scalability  @ www.raleigh.ibm.com @ UGATE
-->  cc: David_Bryant  @ 3mail.3com.com @ UGATE 
-->  From: sbales @ cisco.com (Scott Bales) @ UGATE    
-->  Date: Tuesday  October 15, 1996 05:30 PM
-->  Subject: Re: DLSw Multicast Single Tunnel position
-->  ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
-->  
-->  Dave (et al) -
-->  
-->  The following comments should be read with the knowledge that we (Cisco) are
-->  the vendor that would have the TCP implementation problem.
-->  
-->  The proposal to use 2067 as both source and destination port is at best an
-->  unusual TCP implementation.  Given that it is not illegal, I don't think we
-->  would object as strongly if it solved the problem; however, it solves only 
-->  part of the problem.  It does nothing to alleviate the race conditions 
-->  involving both 2067 (single-port) and 2065 (RFC1795) bringups.  Given that 
-->  these race conditions have to be resolved, we would propose that random 
-->  source ports be permitted in the single-port bringup case, and that we 
-->  address those (relatively simple) race conditions in the spec.  If this 
-->  causes a delay, then so be it.
-->  
-->  If a decision is made to use 2067 as both source and destination port, we
-->  would choose not to implement support for single-port bringup.  However, in
-->  that case we would *vigorously* oppose requiring or assuming single-port 
-->  bringup support in the Multicast/Unicast and Peer-on-Demand (V1.1) spec.
-->  While it may be desirable, there is nothing about single-peer bringup that
-->  is logically required for the Multicast support.
-->  
-->   - Scott Bales, Cisco Systems
-->  
-->  -->  From [email-masked]  Sat Oct 12 02:19:24 1996
-->  -->  From: David.Bryant/HQ/[email-masked]
-->  -->  
-->  -->  Just for the record, here's my position on the single tunnel race 
-->  -->  condition issue.
-->  -->  
-->  -->  I think we should use a source and dest port of 2067 and let 
-->  -->  TCP resolve the race conditions.  DLSw is already complex and 
-->  -->  cpu heavy, I don't see the need to add something to it that already
-->  -->  exists at the lower layers.
-->  -->  
-->  -->  I recognize that certain implementations may not be able to
-->  -->  accomodate sending a specific source port, but to the best 
-->  -->  of my knowledge, only one vendor has this issue.  Since DLSw 
-->  -->  scalability enhancements are an optional enhancement, it 
-->  -->  doesn't seem to make much sense to over complicate the protocol
-->  -->  to resolve one vendor's implementation problem.  Are there other 
-->  -->  vendors with this problem??
-->  -->  
-->  -->  Regards, 
-->  -->  Dave
-->  -->  
-->  
-->  
-->    
-->